[レポート]デザインパターンと顧客事例で見るモダンアプリケーション開発 ~AWSでのモダンアプリケーション開発~ #AWSSummitOnlineKorea

2020AWS Summit online koreaのセッションを整理した記事です。

AWS Summit Online Korea 2020

#AWS

#イベントレポート

Lee Sujae

2020.05.19

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

5月 13日 AWS Summit Onlineが開催されました。
コロナの影響でオンラインとして行われて残念でした…
今回のカンファレンスで特に興味ができたセッションを整理し共有もするためにブログを書きました！
確かにアーキテクチャやデザインパターンに対する内容で難しい用語が多かったので、一緒に見れあれるようにまとめました。
すべての写真の出所はAWS Summit Online Koreaです

セッション概要

デザインパターンと顧客事例で見るモダンアプリケーション開発

べ・ヨンブ(배영부) アプリケーションアーキテクト, AWS
カン・ソンイル(강성일) アプリケーションアーキテクト, AWS

ほぼ全ての産業分野の企業は、かつてない変化を経験しており、小さくて早い企業が数ヶ月で市場をリードしたこともあります。しかし、伝統的なモノリチックアプリケーション環境では市場の変化に素早く対応したり、実験を試みることは困難でした。コンテナとサーバレス技術、MSA、CI/CDの特徴を持つモダンアプリケーションの開発は皆さんが素早く革新できるようお手伝いできます。このセッションでは、実際のビジネスケースのためにAWSに実装した様々なモダンアプリケーションのデザインパターンを事例とともに紹介します。

アジェンダ

モダンアプリケーションの開発
モダンアプリケーションのデザインパターン
デザインパターン別顧客事例

モダンアプリケーションの開発

ぼ全ての産業分野の企業は、かつてない変化を経験しております。現代の企業にとって革新は必須であるだけでなく、非常に速くなければならないということを私たちは経験的に知っています。

現代のビジネスにおける迅速さは非常に重要な要素の一つです。急速に変化していく時代の流れに合わせて、企業は実験を通じて革新的なアイテムをお客様に提供しなければなりません。

革新的な企業は、戦略、企業文化、優秀な人材、そして革新の中心にデジタル技術という共通点を持っています。

AWSはより効率的かつ迅速に革新を達成するための最適なプラットフォームです。

モダンアプリケーションのデザインパターン

現代的なアプリケーションの開発

必要な資源と時間を最小化し、コア・アプリケーションの革新に投資
可能な限りリサイクル可能なビルブロックと共通のアーキテクチャパターンを使用
AWSをアプリケーションのビルブロックとして使用すると、実装に必要な資源を減らし、安定性と可用性を高めることができます。

現代的なアプリケーション実装のための一般的なパターン

API Gateway

使用するAWSサービス

AWS API Gateway

マイクロサービスを効率的に使うためにサービスの特定グループに単一アクセスポイントを提供するパターンです。
注意点は単一API Gatewayがアプリケーションのすべてのマイクロサービスを集計しないようにすることです。

Service Discovery and Service Registries

使用するAWSサービス

AWS Cloud Map
AWS ELB(Elastic Load Balancing)

マイクロサービスアーキテクチャ(以下'MSA')でサービスは、依存する他のサービスのアドレスをいつも見つけることができなければなりません。
MSAでは障害に対応するため、新しいインスタンスまたはコンテナをオンライン状態にするなど、インスタンスやコンテナのIPが継続的に変更されることがあります。
サービスインスタンスは、開始時に自身の情報をservice registriesに登録し、service registriesは、各サービスインスタンスの状態を持続的に点検します。

このパターンはServer-side service discovery patternやClient-side service discovery patternで実現できます。

Server-side service discovery pattern

AWS ELBを活用してステーブル・エンドポイントが提供できます。
ただし、ロードバランスのためには追加的なコンピューティングリソースが必要であり、待機時間が発生する可能性があります。

Client-side service discovery pattern

クライアントがコールを制御できる場合に使用します。AWS Cloud Mapを活用すればクライアントのコールを通じて管理ができます。

Circuit Breaker

使用するAWSサービス

AWS App Mesh

外部システムのエラー、予測不可能なエラーが継続的に発生することを防止する時に使用します。
指定された回数以上のエラーが発生すると、サーキットブレーカーが開いた状態になり、要請をすると直ちにユーザーにエラーを返還、決められた時間が経過すると再び閉じてコールを正常に処理します。
以前は別途のライブラリーやフレームワークを使いましたが、今はサイドカーのあるコンテナ化されたマイクロサービスで処理できます。Envoy Proxyがサイドカーとして配布される場合サービスメッシュの一部として使われることもあります。
このタイプで、Envoy proxyは、データプレーンで使用され、AWSApp Meshがコントロールプレーンの役割をします

CQRS(command query responsibility segregation)

使用するAWSサービス

AWS DynamoDB
AWS RDS(Aurora)
AWS Lambda

データの命令モジュールとクエリーモジュールを分離して独立的に拡張が可能になります。よく整理されたワークロードでDynamoDBで高いキャパシティ拡張性を確保し、RDSで複雑なクエリ機能を提供します。
そしてLambdaを活用してデータを最新の状態に維持します。

Event Sourcing / Fan-out

使用するAWSサービス

AWS Kinesis
AWS Lambda
AWS SNS(Simple Notification Service)
AWS SQS(Simple Queue Service)

イベント中心のアクセス方法で一連のステータス変更イベントを保存し、ビジネスオブジェクトを永続的に保存します。
複数のイベントコンシューマがストリームしてデータを検索できるように、AWS Kinesis Data Streamを使用します。
AWS SNSを使用して様々なファンクションに拡張できます。
Amazon SNSと指定されたLambda関数の間にAmazon SYS待機列を追加してファンクションに対する実行ソースを指定することができます。

Choreography

使用するAWSサービス

AWS Kinesis
AWS Lambda
AWS SNS(Simple Notification Service)
AWS SQS(Simple Queue Service)

複数のサービスがつながり、長い作業を形成する時に使用します。各サービスが特定のイベントに対する応答を独立して行うことができます。

Log Aggregation

使用するAWSサービス

AWS Cloud Watch

ログを均一に保存できる中央リポジトリを有します。特にMSAでは、要請に対して遅延やエラーを把握することは、モノリシックアーキテクチャに比べて困難である場合があります。
そのため、中央に収集されたログとランタイムメトリクスが必要です。
AWSサービス内でのログは、Cloud Watchを活用してログを収集できます。ECSやFargateの場合は、ログドライバを活用して、Cloud Watchへ送ることができます。